Portal — product requirements
portal.riversync.com — customer device monitoring: live telemetry, configuration and connection health for every RiverSync converged micro data center across your sites, whatever its model, plus the service that keeps it running.
1Devices the Portal monitors
RiverSync ships three product families across six models. The fleet is heterogeneous — generations, series and module counts differ — so telemetry shape differs by family and model. Every device on a customer's sites appears in the Portal regardless of family.
| Family | Models | In the field | Telemetry schema |
|---|---|---|---|
| Frigo | frigo 20 · frigo 30 | Edge / small-site enclosures | Refrigeration family — established shape |
| Koelkast | koelkast 20 · koelkast 30 | Larger enclosures, more cooling modules | Refrigeration family — wider module set |
| Nevera | nevera 30 · nevera 40 | Newest generation new to the model | Newer generation/series — additional fields |
2Telemetry data source
Product-facing summary only — the pipeline, schema registry and storage strategy are specified in the Devices domain (SVC-DVC, SVC-9). The Portal does not own this data; it reads it.
Each device emits three independent streams to RiverSync's ingest plane (mTLS, never through the user gateway): telemetry (the live readings), the device twin (reported state + desired configuration), and connection (online/offline transitions). Readings land in a time-series store outside the relational model — the ⚠ the ERD records under PTL-1 — and only Alert rows cross into Postgres. A device catalog maps each unit to its (family, schema-version) so the Portal renders the right metrics per device; a device with no registered schema is read unknown-safe — never silently null-mapped (see PTL-7).
3Requirements
Live device monitoring — dashboards and per-device telemetry (temperature, power, PUE and per-module readings), health states and alert/alarm streams across all site locations. Values stream live and tween in the UI; deltas shown are factual. Telemetry is served from the time-series store, not Postgres (the ERD ⚠).
Alarms are actionable — acknowledge, see cause and effect ("MDC-6610 return air at 41.4°C — 6.4°C above setpoint"), and open a ticket from the alarm.
Per-device maintenance visibility — under the Portal's Maintenance menu (renamed from Agreement), each device shows its single active maintenance agreement — tier (Silver 8×5 NBD · Gold 24×7 ND), servicing partner, period and expiration — above the full list of its previous agreements, sorted latest to oldest. Renewals surface ahead of time (master PRT-2). Specified in the Maintenance PRD (SPEC-PRD-MNT, MNT-1/2).
Service & messaging — tickets are the single Service conversation surface: each ticket carries engineer visit scheduling and the message thread with RiverSync support or the servicing partner. Messages is merged into Tickets (prototype Jun 2026) — there is no separate Messages menu; the conversation lives inside the ticket.
Role-gated — what a member sees and controls (acknowledge, configure, control equipment, firmware) follows the Portal column of Account's permission matrix.
Family & model identity — every device is shown with its family (Frigo · Koelkast · Nevera), model and serial, and its dashboards group and filter by family/model/site. The customer never needs to know about schema versions; the Portal resolves them.
Schema-aware telemetry — metric and field sets differ per family, model and schema version (e.g. Nevera carries fields Frigo does not, and multi-module units report per module). The Portal renders the correct metric set for each device. A device whose schema is uncataloged or unregistered degrades gracefully: identity and connection state still show, its readings are marked unavailable rather than guessed, and it is flagged for RiverSync to catalog — never silently null-mapped or dropped.
Device twin visibility — each device shows its reported state (firmware version, operating mode, current setpoints) and, where permitted, its desired configuration. Configuration changes (setpoints, mode, firmware) are role-gated commands (PTL-5), always audited, and reconcile against the twin's reported state.
Connection state — online/offline, last-seen and link health come from the connection stream. Offline devices are visibly distinct, telemetry gaps are explained by connection loss rather than read as zeroes, and a device going offline can itself raise an alert (PTL-2).
History & export — telemetry is browsable over selectable time windows (with the time-series brush) and exportable. History depth follows the time-series store's retention; any gap from the legacy-store cutover is surfaced, not hidden.